iverilogfandomcom-20200214-history
Development Time Line
This page is meant to be a living document that describes current thinking for what we want to do with Icarus Verilog development. We try to divide our intentions into a release schedule of sorts. Note that there are no dates. It'll be ready when it's ready. The Release Process The release process for Icarus Verilog takes place in the git repository, and is managed by branches and tags. Snapshots Snapshots are tagged points on the master branch. Snapshot tags have the form sYYYYMMDD where YYYY is the year, MM the numeric month and DD the day. Keeping to this format for snapshot tags makes them easy to recognize. Release Candidates A release comes to existence as a branch in the git repository, so that all development on the master branch does not go into the release branch by default. A new branch format v0_X-branch starts the release candidates for the 0.X release series. Initially, there are no release tags on a release branch, and the release isn't really released yet. This is a release candidate branch. The actual candidates are managed in an ad hoc manner up to the first actual release. There may be non-release tags to mark potential releases. Thus we create the branch for the release and put it into a feature freeze. We then have time to polish it up for the first proper release on the branch, and the master can in the mean time continue on with new development. Released Releases The first release will be tagged v0_X_1 for release 0.X.1 and marks the end of the release candidate phase. The next release will be tagged v0_X_2 for release 0.X.2, and so forth. Release tags all have the same format. We start the releases as .1 to leave .0 for the first release candidates. Within a release branch, we try to assure that minimum standards of compatibility are met: * It is necessary that any vvp output generated by iverilog X.Y.m must run under vvp X.Y.n ( m < n ). In other words, backward compatibility within a release series is required. Does this also include messages (textual output)? or is this more simulation output? We need a definition of what output is (simulation results, compiler output, error/warning messages, etc.) * For any program where X.Y.m generates correct output, then X.Y.n ( m < n ) may not change the output, even if the different is also correct by other definitions. * New features should be kept to a minimum, and new features may not create any backward compatibility problems. In other words, if a program compiles and runs correctly on X.Y.m, then it must also compile and run on X.Y.n. For example, no new keywords! * If X.Y.m compiles and runs but generates incorrect output, then X.Y.n may generate different and more correct output. * If the input program is incorrect and X.Y.m compiles it but shouldn't, then X.Y.n may generate error messages instead. Version 0.8.7 * 0.8.7 has been released. We expect this to be the last release in the 0.8 line. We will only do another release if we need to fix critical bugs in the simulator or significant bugs in the synthesis code. Version 0.9.2 We have made a significant number of bug fixes/enhancements since the V0.9.1 release that will not be listed here. The following are what we would like to add before the next release. * Fix pr2881797 (Auto-re-config doesn't necessarily touch output) report. * Fix pr2546206 (Embedded spaces in install paths not supported) for MinGW. The idea here is that the executable will fully support spaces in the paths. We still have a limitation in the Makefile that can not easily be worked around, but the configure script reports an error for this case. For MinGW the executable can be relocated so for it we can install into a non-space path and then relocate during installation into a path with space. This is exactly the case that instigated this report. * Possibly fix pr2874755 (VCD contains "changes" of unchanged values). It would be nice if we could fix this before the release or decide if this is just a feature of the Icarus dumper. * Possibly fix pr2785294 (cbValueChange for a part/bit select runs for any bit changes). This is one of the few higher priority bugs that we may be able to fix in V0.9. The rest require significant changes that can only be implemented in development (v0.10). * Any other V0.9 appropriate bugs that may come up between now and the release date. Next development snapshot (version 0.10.devel) * Not defined yet. Development After 0.9 The following list is for items that do not have a bug report. In general we plan to work on fixing some of the long standing bug reports and add some of the missing functionality for each release. * Verilog-AMS fleshed out enough that it is usable. * Bring back synthesis. * Get specify block to work correctly including implementing the timing checks. * Verify VPI interface functionality against standard functions and add missing functionality that makes sense for Icarus. * Rework the run time support for nets (as opposed to variables) so that they are part of an existing functor. They should not have their own vvp_net object. This should save run-time costs and fix bugs related to force and vpi_put_value to nets. Finished and merged into development. * Add support for dynamic expression evaluation. We have implemented the start of this with the &A<> and &PV<> constructs. We need another construct to support arbitrary expressions. For some expressions this is a bidirectional construct (it can get or put a value). * It would be nice to have the stub target do full checking of the compiler interface and return a value that we can wrap around an alternate test suite script. Basically a stub_reg.pl script that only runs the compiler with -tstub. * Add vzt dump file support. This is another GTKWave file format. See the GTKWave source and the discussion on iverilog-devel. The latest GTKWave (3.2.0) has code that could be used as a template in the contrib/vpi directory. * Finish the valgrind cleanup of vvp and start to look at doing the same for ivl. ivlpp and the iverilog driver should already be clean. * Look at the unreported SDF problem. This may only require the net rework mentioned above. Notes For Planned Tasks Verilog A/MS The long-term plan is for Icarus Verilog to support Verilog-A/MS as completely as regular Verilog. That's a fairly large task and it needs a strategy for tackling it. * Parse and Elaborate The first goal is to properly parse and elaborate a reasonable subset of Verilog-AMS language constructs. This gathers together enough compiler infrastructure for later steps. * Code generation for gnucap Actually implementing the analog run-time can be put off by instead targeting gnucap. The idea here is to write a loadable code generator that emits models for gnucap, which can then simulate that model. This makes the Icarus Verilog analog support useful even at this early stage. * Analog runtime in vvp Add to the vvp runtime support for analog simulation kernels. This amounts to writing a new analog simulator, so this will take some real time. It is unlikely that this will be even started before the 0.9 release.